FIG. 1 is an exemplary illustration of a conventional blade server 100 connected to an external switched fabric. Blade servers overcome some of the inefficiencies of individual standalone or rack-mounted one unit (1 U) high servers, each of which is self-contained and includes separate power supplies, fans, and the like. Individual servers are therefore inefficient in terms of space, power, cooling, and other characteristics. Blade servers 100 utilize a modular, plug-in approach wherein the housing for each server is eliminated along with self-contained components such as power supplies and fans. Each previously standalone server is therefore reduced to a server “blade” 102 (typically eight to 14 in a blade server chassis 106) capable of being plugged into a midplane 104 within the blade server chassis 106 from the front of the chassis. The midplane 104 contains connectors for receiving the server blades 102 and typically contains from one to four “lanes” or paths on a Printed Circuit Board (PCB) for carrying signals. The midplane 104 therefore eliminates much of the cabling that was required with individual servers. The blade server chassis 106 also provides redundant common cooling and power to the server blades 102 through the midplane 104.
Conventional blade servers 100 may be connected to redundant external switch fabrics 108 through an “A” side Input/Output (I/O) switch 110 and a “B” side I/O switch 112, which plug into the midplane 104 from the back of the chassis 106. Typically, the redundancy enables one switch to take over if the other fails. In addition, the blade server midplane is typically plumbed to allow for multiple independent redundant fabrics or I/O protocols, such as Fibre Channel (FC), Serial Attached SCSI (SAS), SATA, Ethernet or InfiniBand. In the case of a FC configuration, each embedded switch 110 and 112 may be a FC Arbitrated Loop (FC_AL) switch or a full fabric switch, with a separate port to receive a FC link 116 from each of the multiple server blades 102, and output ports for connecting to each of the external switched fabrics 108.
To enable the server blades 102 to communicate with the switch fabric, typically a mezzanine I/O card 114 that performs a Host Bus Adapter (HBA) (a.k.a. I/O Controller (IOC)) function is required in each server blade 102. These mezzanine I/O cards 114 are typically mounted to the server blades 102 as daughter cards. Note that this may also be accomplished by embedding an IOC directly on the server blade. However, this increases complexity for the Original Equipment Manufacturer (OEM), who must now make a different server blade for each type of I/O that will be supported. For purposes of this specification, mezzanine I/O cards 114, referred to herein, include both daughter cards and IOCs mounted directly onto the server blade. The output of a mezzanine I/O card 114 is two I/O links 116 routed to each of the two embedded switches 110 and 112. The mezzanine I/O cards 114 follow the standard device driver model, so that when a server blade 102 with a mezzanine I/O card 114 is plugged into the midplane 104 and connected to an embedded switch 110 or 112, it appears to be a standalone server with a Peripheral Component Interconnect (PCI) card communicating with an external switch.
Each conventional server blade 102 has traditionally included two disk drives 118 for redundancy. However, the compact nature of blade servers 100 and the desired small size of the server blades 102 means that the two disk drives 118 normally contained in each server blade take up valuable space.
Modern disk drives contain more storage capacity that is typically needed by a server blade, and thus diskless server blades have been developed in which the physical disk drives are located either in another board within the blade server (an “embedded” implementation) or even in an enclosure outside the blade server (e.g. a storage array connected to the blade server). One company that makes diskless server blades for non-FC applications is Engenera.
Diskless server blades boot off of virtual drives, which are formed within the physical drives. The mapping of server blades and virtual drives has conventionally been a manual process involving adjusting Basic Input/Output System (BIOS) settings and setting up the storage array with a World-Wide Port Name (WWPN) that maps to the server blades and the blade server.
Heretofore, in both blade server and non-blade server applications, there has been no way to automatically create virtual drives and map servers to the virtual drives. However, if the maximum number of allowable servers and drives is known, then a processor executing firmware either within one of the servers or external to the servers can automatically create virtual drives from existing physical drives, map them to existing servers, and allow for servers and drives to be subsequently added to the system (up to the maximum allowable numbers) without disrupting the mapping.
Therefore, there is a need to automatically create virtual drives from existing physical drives and map existing servers to the virtual drives when the maximum number of allowable servers and drives is known, and also to allow for additional servers and drives (up to the maximum allowable numbers) to be added and mapped without disrupting the original mapping.